Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-013.txt

Text File | 1992-11-18 | 43.2 KB | 1,230 lines | [TEXT/MPS ]

C.S.M.P. Digest             Wed, 11 Mar 92       Volume 1 : Issue 13

Today's Topics:

    Getting a non-apple-event-aware app to open a document
    Out of memory? Like hell!
    Avoid using Multi-Finder!!
    SADE "Bad type information" bug ?
    Getting data out of a AEDesc -- the apple way...
    Munger question
    ADB Device Handler ID's anyone?
    PICT creation in temp. memory... how?
    MacApp 2.01 w/ C++ Undo Problems


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu (try skinner.cs.uoregon.edu if that doesn't work).  This is also the home
of the comp.sys.mac.programmer Frequently Asked Questions list.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Jonathan Greenfield)
Subject: Getting a non-apple-event-aware app to open a document
Date: 3 Feb 92 15:46:06 GMT
Organization: CIS Dept., Syracuse University

Can anyone give me a pointer to information on forcing an application that
is not apple-event-aware to open a document.  (As the Finder does)

It's no problem to launch an application and get it to open a document
(then, the Finder will automatically convert an 'odoc' event into the
appropriate form).  But if the application is already running, it is a
bit more difficult.

Thanks for any info.

--
greeny                                           [e-mail]

"What's the difference between an orange?"



- -------------------------

From: [e-mail] (Joe Francis)
Subject:  Getting a non-apple-event-aware app to open a document
Date: 4 Feb 92 11:54:15 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Jonathan Greenfield) writes:
> Can anyone give me a pointer to information on forcing an application that
> is not apple-event-aware to open a document.  (As the Finder does)
> It's no problem to launch an application and get it to open a document
> (then, the Finder will automatically convert an 'odoc' event into the
> appropriate form).  But if the application is already running, it is a
> bit more difficult.

Under system 7, you send it an 'odoc' event.  If the target process has
a File menu with an Open item, system 7 will fake a
mousedown/menuselect/sfgetfile sequence to prod the app into opening
the appropriate document.



- -------------------------

From: [e-mail]
Subject:  Getting a non-apple-event-aware app to open a document
Date: 3 Feb 92 18:44:47 GMT
Organization: Campus Computing Sites, University of Michigan-Ann Arbor

In article <[e-mail]> [e-mail] (Jonathan Greenfield) writes:
>Can anyone give me a pointer to information on forcing an application that
>is not apple-event-aware to open a document.  (As the Finder does)
>
>It's no problem to launch an application and get it to open a document
>(then, the Finder will automatically convert an 'odoc' event into the
>appropriate form).  But if the application is already running, it is a
>bit more difficult.
>
    As long as you are only concerned with System 7, and are sending
'odoc' events to the application - it doesn't matter whether the recieve is
AEVT aware or not.  The Process Manager & the AE Manager will play some games
to get your 'odoc' converted into 'MultiFinder Puppet Strings" so that the
document will open.
    This is also true for the 'quit' event as well, though not for the
teh 'pdoc' event since MF never puppet stringed that one since it has a number
of technical problems.

    If you wanted to open docs in already running apps under Sys6 you
would have to reimplement the 'puppet string' mechanism yourself which
requires either an INIT or a driver.

--
- ---------------------------------------------------------------------
Leonard Rosenthol          Internet: [e-mail]
Director of Advanced Technology   AppleLink: MACgician
Aladdin Systems, inc.          GEnie:     MACgician



- -------------------------

From: [e-mail] (Jonathan Greenfield)
Subject:  Getting a non-apple-event-aware app to open a document
Date: 7 Feb 92 17:29:01 GMT
Organization: CIS Dept., Syracuse University

In article <[e-mail]> [e-mail] writes:

>>It's no problem to launch an application and get it to open a document
>>(then, the Finder will automatically convert an 'odoc' event into the
>>appropriate form).  But if the application is already running, it is a
>>bit more difficult.
>>
>    As long as you are only concerned with System 7, and are sending
>'odoc' events to the application - it doesn't matter whether the recieve is
>AEVT aware or not.  The Process Manager & the AE Manager will play some games
>to get your 'odoc' converted into 'MultiFinder Puppet Strings" so that the
>document will open.

(Yes, this is for System 7.)

This may be true in theory, but it does not seem to be the case in practice.
One of the "snippets" specifically mentions that the *Finder* performs the
conversion to "puppet strings" when it sees an 'odoc' event.  (This was in
reference to launching an application with an 'odoc' event passed as a
parameter.)

I guessed that it might work for 'odoc' events sent to apps that were
already running--but it just doesn't seem to work.  The 'odoc' event is
properly accepted by apple-event-aware apps, but not by other apps.

Furthermore, the problem is not the absence of an appropriate "Open..."
menu item (or an appropriate mstr resource), because drag-and-drop from the
Finder works on these apps (even when they are already running).

So here is the basic problem I am having:

   1) Program is successful in launching applications and *at the same time*
      opening a document (or documents), for all applications that support
      drag-and-drop.

   2) Program is successful in coercing an apple-event-aware app into
      opening a document (or documents), when it is already running.

   3) Program *fails* to coerce non-apple-event-aware apps into opening
      a document (or documents), when they are already running.


This problem has really baffled me.  Does anybody have any idea why the
"puppet string" conversion might fail to work as advertised?

(It would seem to me that more has to be done by the Finder to coerce a
*running* app to open a document, than for one that is just being launched.
But a few people have claimed that sending an 'odoc' event works.  How did
you do it?!  Did you do something special?)

Thanks for any help.

--
J. S. Greenfield                                         [e-mail]
(I like to put 'greeny' here,
but my d*mn system wants a
*real* name!)                        "What's the difference between an orange?"



- -------------------------

From: [e-mail] (Daniel Norman Johnson)
Subject:  Getting a non-apple-event-aware app to open a document
Organization: Information Technology Services, Rennselaer Polytechnic Institute.
Date: Sat, 8 Feb 1992 18:14:05 GMT

> - Various things about AppleEvents omited, because I'm not even going to
> - mention AppleEvents after this line...

>   3) Program *fails* to coerce non-apple-event-aware apps into opening
>      a document (or documents), when they are already running.


> This problem has really baffled me.  Does anybody have any idea why the
> "puppet string" conversion might fail to work as advertised?

> (It would seem to me that more has to be done by the Finder to coerce a
> *running* app to open a document, than for one that is just being launched.
> But a few people have claimed that sending an 'odoc' event works.  How did
> you do it?!  Did you do something special?)

> Thanks for any help.

One point- for the MultiFinder faking trick to work (why is it called
Puppet Strings, any way?), the app that is going to do the open command MUST
have an "Open..." command, *NOT* an "Open" command; the 3 .s matter!

The way the finder passes documents to be opened to an app that it launches is quite different- the app has to solicit the info in question. So check that
one point. It may be that the Apple Event manager IS doing the coercion, but
that it is not working because of this.



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  Getting a non-apple-event-aware app to open a document
Date: 8 Feb 92 22:19:58 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

@vccsouth28.its.rpi.edu (Daniel Norman Johnson) writes:

   One point- for the MultiFinder faking trick to work (why is it called
   Puppet Strings, any way?), the app that is going to do the open command MUST
   have an "Open..." command, *NOT* an "Open" command; the 3 .s matter!

That's not true. The application can add "mstr" resources or
"mst#" resources to explain what menu items to use (how would
foreign software work else ?)

By the way, it's called "puppet strings" because MultiFinder
leads the app into opening a document by pulling "strings" to
the document (menu here, dialog there, shortcut a selection...),
much like one of those dog/man/lizard puppets you can buy in
the street :-)

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

From: [e-mail] (Jonathan Greenfield)
Subject:  Getting a non-apple-event-aware app to open a document
Organization: CIS Dept., Syracuse University
Date: Sun, 9 Feb 92 21:57:57 EST

In article <82csz##@rpi.edu> [e-mail] writes:
>
>One point- for the MultiFinder faking trick to work (why is it called
>Puppet Strings, any way?), the app that is going to do the open command MUST
>have an "Open..." command, *NOT* an "Open" command; the 3 .s matter!

True enough (or you need appropriate mstr or mst# resources).  This was not
the problem here.  (Document opening worked fine from the Finder, itself.)

It turns out that not waiting for a reply to the apple-event was the
problem.  (See previous post.)  Just one of those strange, undocumented
requirements, I guess.

--
J. S. Greenfield                                         [e-mail]
(I like to put 'greeny' here,
but my d*mn system wants a
*real* name!)                        "What's the difference between an orange?"



---------------------------

From: [e-mail] (Steve Howell)
Subject: Out of memory? Like hell!
Date: 5 Feb 92 14:05:32 GMT
Organization: University of Tasmania, Australia.

Why is memory management on the Macintosh so primitive? I am running
system 7 on a Quadra with 20 Megabytes of RAM. When I attempt to edit
my resource file with ResEdit, I frequently get "Memory is getting
dangerously low - it would be a good idea to close some windows now."
It is particularly infuriating when it vetoes copy and paste operations
due to a lack of memory when I have ResEdit jacked up to something stupid
like 4 Mb and the system shows 13 Mb of ram is idle. It would appear that
it is the finder itself running out of memory. How to I give it more
working space? I hate the way it runs out all the time. I'd give it a
whole extra meg. if I could. Is there a program to do this? I have
tried bootman to no avail. Help! This is driving me mad!

- Steve.



- -------------------------

From: [e-mail] (Scott Howard)
Subject:  Out of memory? Like hell!
Date: 5 Feb 92 16:59:30 GMT
Organization: University of Illinois at Urbana

Perhaps you have set ResEdit to Pig Mode?


--
All views expressed are copyright 1992 Scott Howard. Any resemblance to
living persons, historical events, or logically constructed arguements
is purely unintentional.



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  Out of memory? Like hell!
Date: 5 Feb 92 17:34:54 GMT
Organization: Kalamazoo College

[e-mail] (Steve Howell) writes:
>Why is memory management on the Macintosh so primitive?

JMP _Conclusions    ; is this really necessary?

>I am running
>system 7 on a Quadra with 20 Megabytes of RAM. When I attempt to edit
>my resource file with ResEdit, I frequently get "Memory is getting
>dangerously low - it would be a good idea to close some windows now."

I frequently get this error when attempting to edit corrupted files.  I
don't know if it's because the files' lengths are set to something
randomly huge, or because the aforementioned error is ResEdit's standard
"something has gone wrong" message.
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (Brian Gregory Howard)
Subject:  Out of memory? Like hell!
Date: 5 Feb 92 23:45:50 GMT
Organization: Kansas State University

[e-mail] (Jamie R. McCarthy) writes:

>>I am running
>>system 7 on a Quadra with 20 Megabytes of RAM. When I attempt to edit
>>my resource file with ResEdit, I frequently get "Memory is getting
>>dangerously low - it would be a good idea to close some windows now."

>I frequently get this error when attempting to edit corrupted files.  I
>don't know if it's because the files' lengths are set to something
>randomly huge, or because the aforementioned error is ResEdit's standard
>"something has gone wrong" message.

I had this problem the other day with ResEdit2.1.  I was tinkering with a
DLOG resource and did something wrong.  I finally had to salvage what I could
from the resource file and trash it.

                    Brian Howard
                    [e-mail]
                    [e-mail]



- -------------------------

From: [e-mail] (David Peterson)
Subject:  Out of memory? Like hell!
Date: 7 Feb 92 01:32:18 GMT
Organization: University of Southern California, Los Angeles, CA


This is a sort of irritating though.

Every once in a while I'll be doing something in ResEdit and it will run
out of memory. Okay fine, quit it and up its memory partion and try again.

It always works out though that I set it to something obcenely large and
then forget to set it back before I start programming again. Then either
CFront or Link run out of memory or take forever because ResEdit stole their
memory from the system (and is now doing nothing with it).

Could ResEdit be changed to use spare system memory "on demand" like some
of the MPW tools do? I rarely need more than the suggested 500k, but when
I do I usually end up going through the above scenario.

-dave.



- -------------------------

Subject:  Out of memory? Like hell!
From: [e-mail]
Date: 10 Feb 92 03:52:28 CST
Organization: University of Missouri Computing Services

In article <steveh.697298732@tasman>, [e-mail] (Steve Howell) writes:
> Why is memory management on the Macintosh so primitive? I am running

Hmm, Because the roots of the memory manager are in the paint program
that shipped with the Lisa 8 years ago, which worked pretty well on
an 128K mac.

> system 7 on a Quadra with 20 Megabytes of RAM. When I attempt to edit
> like 4 Mb and the system shows 13 Mb of ram is idle. It would appear that
> it is the finder itself running out of memory. How to I give it more
> working space? I hate the way it runs out all the time. I'd give it a
> whole extra meg. if I could. Is there a program to do this? I have

Mount your harddrive from system 6 (you'll have to do this on another
mac, I think - quadras won't run 6 will they?) do a get info on the
finder and increase its memory partition to the size desired.

Jonathan/[e-mail]



---------------------------

From: [e-mail] (Ming-Tsung Darda Chang)
Subject: Avoid using Multi-Finder!!
Date: 6 Feb 92 03:44:04 GMT
Organization: University of Minnesota, Minneapolis, CSci dept.

Hi, Folks:

I really need some helps or any hint to avoid using Multi-Finder when running
my program!!  I have been reading through the Tech. notes,
Inside Macintosh I-VI, but still can not help me come up with any idea.
I do hope any expert there can give me any kind of help to make my program work
on Multi-Finder without using Multi-Finder!!

I am using Think C 5.0.2.  Any kind of demo source code is appreciated!!

Thanks for your help!

Darda
--
========================================================================
= Mr. Ming-Tsung Darda Chang                                           =
=----------------------------------------------------------------------=
= Computer Science Department              Internet: [e-mail] =



- -------------------------

From: [e-mail] (Doug McNaught)
Subject:  Avoid using Multi-Finder!!
Organization: California Institute of Technology
Date: Thu, 6 Feb 1992 05:17:29 GMT

In article <[e-mail]> [e-mail] (Ming-Tsung Darda Chang) writes:
>Hi, Folks:
>
>I really need some helps or any hint to avoid using Multi-Finder when running
>my program!!  I have been reading through the Tech. notes,
>Inside Macintosh I-VI, but still can not help me come up with any idea.
>I do hope any expert there can give me any kind of help to make my program work
>on Multi-Finder without using Multi-Finder!!

 I'm not sure exactly what you mean. If you want to refuse to run under MF,
there is no 'official' way to know whether MF is active or not. Otherwise, I
can't puzzle out your prose--could you clarify?
doug
--
<><><><><><><><><><><><><><><>Go Skins!!<><><><><><><><><><><><><><><><>
<> Doug McNaught                          [e-mail] <>
<>         Legalize it / Don't criticize it --- Peter Tosh            <>
<><><><><><><><><><><><><><><>Go Skins!!<><><><><><><><><><><><><><><><>



- -------------------------

From: [e-mail] (Paul Gerard de Jong)
Subject:  Avoid using Multi-Finder!!
Date: 10 Feb 92 09:58:39 GMT
Organization: FWI, University of Amsterdam

This is probably the most completely unclear newsmessage of the year.
What is the problem, and what is your question ?

[e-mail] (Ming-Tsung Darda Chang) writes:
>Hi, Folks:

>I really need some helps or any hint to avoid using Multi-Finder when running
>my program!!  I have been reading through the Tech. notes,
>Inside Macintosh I-VI, but still can not help me come up with any idea.
>I do hope any expert there can give me any kind of help to make my program work
>on Multi-Finder without using Multi-Finder!!

>I am using Think C 5.0.2.  Any kind of demo source code is appreciated!!

>Thanks for your help!

>Darda
>--
>========================================================================
>= Mr. Ming-Tsung Darda Chang                                           =
>=----------------------------------------------------------------------=
>= Computer Science Department              Internet: [e-mail] =



---------------------------

From: [e-mail] (Brian Cuthie)
Subject: SADE "Bad type information" bug ?
Organization: University of Maryland Baltimore Campus
Date: Thu, 6 Feb 1992 16:12:14 GMT


I'm debugging a rather large Mac application with SADE.  In the process
I seem to have stumbled accross my favorite SADE bug[feature].  The
problem is that when trying to examine a rather large struct (610 bytes)
that's been allocated locally, SADE prints the first 6 members of the
struct and then quits with:

    ### Bad type information in symbol file (618)

Anybody know what's going on here ? This problem occurs in versions of
SADE ranging from 1.0 to 1.3b1.  Am *I* doing something wrong ?
I've tried recompiling, etc., but nothing seems to have any effect.

Thanks.

-Brian





- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  SADE "Bad type information" bug ?
Date: 8 Feb 92 01:34:14 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Brian Cuthie) writes:
>
>
> I'm debugging a rather large Mac application with SADE.  In the process
> I seem to have stumbled accross my favorite SADE bug[feature].  The
> problem is that when trying to examine a rather large struct (610 bytes)
> that's been allocated locally, SADE prints the first 6 members of the
> struct and then quits with:
>
>     ### Bad type information in symbol file (618)
>
> Anybody know what's going on here ? This problem occurs in versions of
> SADE ranging from 1.0 to 1.3b1.  Am *I* doing something wrong ?
> I've tried recompiling, etc., but nothing seems to have any effect.

The latest official release is 1.3.1, check out if the problem is still
there.

Kent



---------------------------

From: [e-mail] (Gordon Watts -- U of Rochester)
Subject: Getting data out of a AEDesc -- the apple way...
Date: 7 Feb 92 04:28:07 GMT
Organization: Fermilab

Hi all,
  Got a quick question.  I'm working with apple events.  Lets say I have an
AEDesc whose descriptorType field is typeAlias.  I want to turn it into a
FSSPec record, and get out (so I can use it in a file manager call, for
example).  After much puzzeling, I can find no routine to do this for me --
unless I go back to AEList it came from (which I would prefer not to do).  I
need something like AEGetPtr which would pull the data out of a AEDesc...

  The only think I could think of was to use AECoerceDesc as follows:

    theErr = AECoerceDesc (theAliasDesc, typeFSS, theNewFSSDesc)

and then use theNewFSSDesc.dataHandle directly.  However -- apple sais, in IM
vol 6, p 6-9 top "the data referred to by the dataHandle in the descriptor
record is private to the Apple Event Manager.  You can supply or extract this
data only by using Apple Event Manager routines."  I haven't tried this
approach yet, as I haven't had time.  I thought I would ask the net first...

  Is there some routine that will get me the data out of a plain AEDesc?

    Thanks,
        Gordon.



- -------------------------

From: [e-mail] (Grobbins)
Subject:  Getting data out of a AEDesc -- the apple way...
Date: 9 Feb 92 01:38:20 GMT
Organization: The Johnson Administration

In article <QHP#[e-mail]> [e-mail] writes:
>Lets say I have an AEDesc whose descriptorType field is typeAlias.
>...  After much puzzeling, I can find no routine to do this for me --
>unless I go back to AEList it came from (which I would prefer not to do).

Unfortunately, there is no routine to act as the inverse of AECreateDesc.
Usually the matter doesn't come up, since raw data is retrieved from
descriptor lists with calls like AEGetParamPtr.  But if you really have an
atomic descriptor, go ahead and grab the datahandle.

>    theErr = AECoerceDesc (theAliasDesc, typeFSS, theNewFSSDesc)
>and then use theNewFSSDesc.dataHandle directly.

That's fine, or you could extract the alias record and call ResolveAlias
or MatchAlias on it.

Grobbins                [e-mail]

Usual disclaimers apply.



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  Getting data out of a AEDesc -- the apple way...
Date: 9 Feb 92 10:50:50 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Grobbins) writes:

   Usually the matter doesn't come up, since raw data is retrieved from
   descriptor lists with calls like AEGetParamPtr.  But if you really have an
   atomic descriptor, go ahead and grab the datahandle.

   >    theErr = AECoerceDesc (theAliasDesc, typeFSS, theNewFSSDesc)
   >and then use theNewFSSDesc.dataHandle directly.

   That's fine, or you could extract the alias record and call ResolveAlias
   or MatchAlias on it.

That's not what IM VI says. IM VI says: NEVER EVER IN A MILLION YEARS
EVEN THINK about accessing the datahandle directly. It could be a magic
token for all you know. Especially when there is a ocumented way of
getting data out of the descriptor:

    - Create a list
    - Add the desc
    - GetNthPtr
    - Dispose list

One could even wrap that up in an utility function.

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

From: [e-mail] (Ed Lai)
Subject:  Getting data out of a AEDesc -- the apple way...
Date: 10 Feb 92 17:38:23 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <QHP#[e-mail]> [e-mail] writes:
>Hi all,
>  Got a quick question.  I'm working with apple events.  Lets say I have an
>AEDesc whose descriptorType field is typeAlias.  I want to turn it into a
>FSSPec record, and get out (so I can use it in a file manager call, for
>example).  After much puzzeling, I can find no routine to do this for me --
>unless I go back to AEList it came from (which I would prefer not to do).  I
>need something like AEGetPtr which would pull the data out of a AEDesc...
>
>  The only think I could think of was to use AECoerceDesc as follows:
>
>    theErr = AECoerceDesc (theAliasDesc, typeFSS, theNewFSSDesc)
>
>and then use theNewFSSDesc.dataHandle directly.  However -- apple sais, in IM
>vol 6, p 6-9 top "the data referred to by the dataHandle in the descriptor
>record is private to the Apple Event Manager.  You can supply or extract this
>data only by using Apple Event Manager routines."  I haven't tried this
>approach yet, as I haven't had time.  I thought I would ask the net first...
>
>  Is there some routine that will get me the data out of a plain AEDesc?
>
>    Thanks,
>        Gordon.

An AEDesc is a structure with four character ID, and a data handle. When
they four character ID is a private type, then the data in the data handle
is private. When it is a public type like PICT, TEXT, alis or private type
of your own, you can just take the handle and use it directly. The reverse
is also true. The way to make an alias AEDesc is to make the alias handle
using whatever toolbox call you like, then just assign it as the dataHandle
in the AEDesc and assign its descriptorType to 'alis'.

Actually there should be an easier solution to your problem. Where did you
get the alias Desc in the first place. I can guess it is either

1) you fetch it as a parameter from an Apple Event
2) you fetch it as an item from a Apple Event list.

In either case, when you do the fetch, do it as

AEGetKeyPtr/AEGetNthPtr(event/list, key/index, 'fss ', actualType, @theFss,
  sizeof(theFss), actualSize);

(actually it is not exactly that, since AEGetKeyPtr has a different interface
from AEGetNthPtr, but you get the idea).

And that is it, if it succeed, you can then use theFss directly.

/* Disclaimer: All statments and opinions expressed are my own */
/* Edmund K. Lai                                               */
/* Apple Computer, MS37-UP                                     */
/* 20525 Mariani Ave,                                          */
/* Cupertino, CA 95014                                         */
/* [phone]                                               */
zW@h9cOi



---------------------------

From: [e-mail] (Matthew Hall)
Subject: Munger question
Organization: Oberlin College Computer Science
Date: Fri, 7 Feb 1992 16:33:08 GMT

Actually, I suppose that this is more a question of gethandlesize and
sethandlesize.
    How can I tell if I have enough free memory to increase the
size of a data block with munger, before I try to use it.  I.E, I am
replacing a selection of sampled sound with another selection of
sampled sound, and I need to know, will it fit?  Just checking the
free memory won't work, since as IMII says, I could have 18meg left,
but if a non-relocatable block is positioned above the block I'm
mungering, my block can't grow. The memory management is good enough
so that I don't have really fragmented heap, but before this routine,
I have to lock the handle to the block I'm inserting, or perhaps,
memory is just running low.  Is there a function which will return the
maximum size that a block in memory can grow?  Any Pascal or C source
welcome.

Thank you,
Matt Hall
Alternate mail address [e-mail]

--

<<[e-mail] OR
<<[e-mail]

This is just a beta version signature




- -------------------------

From: [e-mail] (Michael Hecht)
Subject:  Munger question
Organization: SAS Institute Inc.
Date: Mon, 10 Feb 1992 17:11:55 GMT

In article <[e-mail]>,
[e-mail] (Matthew Hall) writes:
>     How can I tell if I have enough free memory to increase the
> size of a data block with munger, before I try to use it.
> [...] before this routine,
> I have to lock the handle to the block I'm inserting, or perhaps,
> memory is just running low.

Matt,

I would suggest two things:

*  Before locking the handle to the block to be inserted, call MoveHHi on it.
That way, it won't affect the Munger operation later on in any adverse way:

   MoveHHi( insertHandle );
   HLock( insertHandle );

*  Just assume the Munger will work, then check the resulting size afterwards
to see if it's what you expected. If not, then it must have failed. You can
try moving your destination handle high in the heap, compact the heap, and
try the Munger again. Here's a routine that's worked for me:

OSErr ReplaceMem( Handle h, Size offset, Size oldSize,
                                 Ptr newData, Size newSize )
{
    Size            finalSize;


    /* Compute resulting size */
    finalSize = GetHandleSize( h ) - oldSize + newSize;

    /* Give it a shot */
    Munger( h, offset, 0, oldSize, newData, newSize );
    if( finalSize == GetHandleSize( h ))
        return noErr;

    /* Didn't work--blast some space in the heap */
    MoveHHi( h );
    CompactMem( finalSize );

    /* Then try again */
    Munger( h, offset, 0, oldSize, newData, newSize );
    if( finalSize != GetHandleSize( h ))
        return memFullErr;

    /* It worked this time */
    return noErr;
}


Hope this helps!

--Michael

=======================================================================
Michael P. Hecht                 | Internet:  [e-mail]
SAS Institute Inc.; Cary, NC USA | AppleLink: SAS.HECHT



---------------------------

From: [e-mail] (Dan Costin)
Subject: ADB Device Handler ID's anyone?
Date: 7 Feb 92 21:41:56 GMT
Organization: Department of Cognitive Science, UCSD

Is there a list of ADB device handler ID's out there anywhere?
Apple's Guide to Hardware mentions ID = 2 or 3 for keyboards,
ID = 1 or 2 for mice.  They also say you must register your ID with them.
Is the list of registered devices available?

Furthermore, how can ID 2 be used by either a mouse or a keyboard,
and where does it say that the keyboard on a Classic has an ID of 8,
which it does?

Thanks in advance for any leads.
-dan



- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Subject:  ADB Device Handler ID's anyone?
Date: 10 Feb 92 22:43:28 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] (Dan Costin) writes:
> Is there a list of ADB device handler ID's out there anywhere?
> Apple's Guide to Hardware mentions ID = 2 or 3 for keyboards,
> ID = 1 or 2 for mice.  They also say you must register your ID with them.
> Is the list of registered devices available?
>
> Furthermore, how can ID 2 be used by either a mouse or a keyboard,
> and where does it say that the keyboard on a Classic has an ID of 8,
> which it does?
>
> Thanks in advance for any leads.
> -dan

Here are the default addresses as we assign them:
1 - security devices (dongles, etc.)
2 - keyboards
3 - mice (relative pointing devices)
4 - tablets (absolute pointing devices)
5 - modems
7 - miscellaneous

To register a device, you must purchase an ADB license from software licensing.  (You
need a license to sell an ADB device at all, due to Apple's patents on the bus). Apple
will then assign you a default address and a handler ID.  The list of assigned IDs is
not available.

Tim Dierks
MacDTS, but I speak for myself



---------------------------

From: [e-mail] (Eric J. Baumgartner)
Subject: PICT creation in temp. memory... how?
Date: 8 Feb 92 00:20:26 GMT
Organization: Dartmouth College, Hanover, NH

I want to be able to create a PICT in temporary memory in System 7,
rather than my applications partition.  Normally, I'd just do:

PicHandle myPICT;

myPICT = OpenPicture(&aRect);

/* all the drawing and copybits commands */

ClosePicture();

IM 6 has calls to create a handle in temp memory, after which you can
use regular memory management functions.  But I can't use these with
OpenPicture, because it's "special"; it signals QD to begin capturing
calls.

How do I do this?  Can I fake it through the QD bottlenecks?  Do I call
OpenPicture and then diddle with the ports picSave to do this?  These
approaches seem plausible but I'm hoping someone who's done it can tell
me definitively.

Eric Baumgartner                   *  [e-mail]
Interactive Media Lab              *  - When in danger or in doubt,
Dartmouth Medical School           *      run in circles, scream and
shout.



- -------------------------

From: [e-mail] (Nobukazu Toge)
Subject:  PICT creation in temp. memory... how?
Date: 9 Feb 92 20:58:52 GMT
Organization: Stanford Linear Accelerator Center

Eric J Baumgartner ([e-mail]) asked -

> I want to be able to create a PICT in temporary memory in System 7,
> rather than my applications partition.  Normally, I'd just do:
>
> PicHandle myPICT;
>
> myPICT = OpenPicture(&aRect);
>
> /* all the drawing and copybits commands */
>
> ClosePicture();
>
> IM 6 has calls to create a handle in temp memory, after which you can
> use regular memory management functions.  But I can't use these with
> OpenPicture, because it's "special"; it signals QD to begin capturing
> calls.
>
> How do I do this?

I am curious to hear anyone's success story, too.  I think I know three
possible work-arounds, but none of them I really fully tested -

1. Diddle the QD bottle necks so that -
    o Spool out the entire picture to a disk file first.
    o Figure out the size of the picture when done.
    o Request a temp memory knowing the picture's size.
    o Dump the data back into the memory.
    o Delete the pict file and pretend nothing has happened.
    o This should work whether under sys-6 or 7.

2. Fool the system by -
    o Do a temp mem allocation call for a tiny small amount of memory.
    o Find out the zone of the block that has been allocated. Discard
      the tiny memoy block allocated in the first step.
    o SetZone to that zone (that is, something like MF zone or ProcMgr?
      zone).
    o OpenPicture
    o QD calls
    o ClosePicture
    o SetZone back to your application zone.

3. Fool the OpenPicture by -
    o Knowing that OpenPicture makes a couple of (three?) NewHandle calls,
    o Patch NewHandle, right before calling OpenPicture, so that a
      NewHandle call in fact calls TempNewHandle.  I guess this patch will
      have to be a tail-patch, so we need to watch out.
    o OpenPicture
    o QD calls
    o ClosePicture
    o Unpatch NewHandle
    o Probably only under sys 7, this may be ok.

I have tried 1 and it basically works OK.  Since everything is within the
"legal" framework of IM, I think it's the safest.
I have tried 2, and it didn't work well (back in sys-6 days).  It was
upsetting MF badly, but it may be because I was doing the entire thing from
within another trap patch... or maybe I simply had some code errors.
I have never tried 3... it's just an idea.  [In my case the problem was that
in general I do not know the size of the picture yet when I call OpenPicture]

Regards,

- Nobu Toge (Stanford Linear Accelerator Center)

* My employer SLAC, Stanford University and U.S. DoE are not reponsible
* for this posting.  My opinion is only mine, unless someone else shares
* it.



- -------------------------

From: [e-mail] (Marc T. Kaufman)
Subject:  PICT creation in temp. memory... how?
Date: 9 Feb 92 23:32:32 GMT
Organization: CS Department, Stanford University, California, USA

[e-mail] (Nobukazu Toge) writes:

>Eric J Baumgartner ([e-mail]) asked -

-> I want to be able to create a PICT in temporary memory in System 7,
-> rather than my applications partition.  Normally, I'd just do:
->...
-> IM 6 has calls to create a handle in temp memory, after which you can
-> use regular memory management functions.  But I can't use these with
-> OpenPicture, because it's "special"; it signals QD to begin capturing
-> calls.
->
-> How do I do this?

>I am curious to hear anyone's success story, too.  I think I know three
>possible work-arounds, but none of them I really fully tested -

>1. Diddle the QD bottle necks so that -
>    o Spool out the entire picture to a disk file first.
>    o Figure out the size of the picture when done.
>    o Request a temp memory knowing the picture's size.
>    o Dump the data back into the memory.
>    o Delete the pict file and pretend nothing has happened.
>    o This should work whether under sys-6 or 7.

Why not just replace the picSpool bottleneck and move the data to the
temp memory handle (growing the handle if necessary), rather than putting
it on disk first and then reading it in?

--
Marc Kaufman ([e-mail])



- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  PICT creation in temp. memory... how?
Date: 10 Feb 92 01:27:30 GMT
Organization: University of Waikato, Hamilton, New Zealand

Put it in the system heap!

    SetZone(SystemZone());
    MyPicture := OpenPicture(Bounds);
    SetZone(PreviousZone);
    ...
    ClosePicture

The system heap is a LOT simpler to deal with than the MultiFinder heap--
no special rules about which Memory Manager calls will or will not work
under which system version, and you can get just about any part of the
system to do its memory allocation there--as witness the above example.

Just remember to check that MultiFinder/Process Manager is actually
present (by testing for the $A88F trap) before doing this.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
To someone with a hammer and a screwdriver, every problem looks
like a nail with threads.



---------------------------

From: [e-mail]. (Kim Drongesen)
Subject: MacApp 2.01 w/ C++ Undo Problems
Date: 7 Feb 92 18:01:11 GMT
Organization: Hewlett-Packard Co., Corvallis, OR, USA

I am running MacApp 2.01 and using C++.  I have been implementing the cut/copy/
clear functionality for my application, and can not get the 'Undo' menu
item to highlight.  All 3 of the command appear to work, and  I
can get my 'cut' items to appear in the clipboard.  However, after the
command has been executed, the Undo menu remains disabled (although it
does say 'Undo Cut', 'Undo Clear', or whatever).

I looked in the MacApp programmer's manual last night, it said that Undo
would be enabled (by MacApp) when the following circumstances are true:

1.  You create and return a TCommand* object from your DoMenuCommand
method.

2.  The fCanUndo field of that object is set to true.

3.  The DoIt command for the command object has been executed (which
sets the fCmdDone field of the command object to true).

4.  There has not been another command executed since your command was
created.

I bring up an inspector window - and for all of the above except 4, I can
verify that these have been done.  Since I only create a Command object
in this portion of my code,  I can't imagine that another Command is being
created (unless MacApp is doing it).

I would appreciate any help from anyone who has seen this before, but I
would also appreciate any debugging tips.  How do I figure out what magic
incantation MacApp is conjuring up to figure out that the Undo item needs
to be disabled?

Any and all suggestions are welcome!!

Thanks in advance,

Kim Drongesen
[e-mail]



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  MacApp 2.01 w/ C++ Undo Problems
Date: 9 Feb 92 23:48:21 GMT
Organization: MacDTS Mongols

In article <[e-mail].>, [e-mail]. (Kim Drongesen) writes:
>
> I am running MacApp 2.01 and using C++.  I have been implementing the cut/copy/
> clear functionality for my application, and can not get the 'Undo' menu
> item to highlight.  All 3 of the command appear to work, and  I
> can get my 'cut' items to appear in the clipboard.  However, after the
> command has been executed, the Undo menu remains disabled (although it
> does say 'Undo Cut', 'Undo Clear', or whatever).

Have you created a buzzword entry in the resource file, something
like (ad hoc):

resource 'cmnu' (128){
    128,
 textMenuProc,
 allEnabled,
 enabled,
 "Buzzwords",
 {
     "My Undo Command", noIcon, noKey, noMark, plain, cMyUndoCommand;
 }
};

Note that this menu cmnu is *not* added to the MBAR resource listing.

Don't know if this was the problem... Check out the examples in
the MacApp 2.0.1 distribution, such as Calc.

(Kent-Sandvik)



- -------------------------

From: [e-mail] (Chuck McMath)
Subject:  MacApp 2.01 w/ C++ Undo Problems
Date: 10 Feb 92 12:49:43 GMT
Organization: MSD

In article <[e-mail].>, [e-mail]. (Kim Drongesen) writes:
>
> I am running MacApp 2.01 and using C++.  I have been implementing the cut/copy/
> clear functionality for my application, and can not get the 'Undo' menu
> item to highlight.  All 3 of the command appear to work, and  I
> can get my 'cut' items to appear in the clipboard.  However, after the
> command has been executed, the Undo menu remains disabled (although it
> does say 'Undo Cut', 'Undo Clear', or whatever).
>
>   (stuff deleted)
>
> Any and all suggestions are welcome!!
>
> Thanks in advance,
>
> Kim Drongesen
> [e-mail]
>
>

It might have something to do with the document of your cut, copy, etc. When
you create the command you have to give it a document, right?  If that doc
is not in the target chain then the undo menu item will have the correct
text, but will not be enabled.  Check out the code in TApplication.SetupTheMenus
(following is a comment from that method):

              { Enable Undo only if the last command was not document-specific
               or the document changed is the current document. }

So, it will only enable Undo if the document passed was NIL or was the same as the
document in the target chain.

Hope this helps,

chuck

                       --chuck mcmath-
                    [e-mail]
  MSD, Inc. * National Library of Medicine * National Institutes of Health
                       Bethesda, MD 20894

 "Competing in the 1994 Winter Olympics newest demonstration sport - snow angels!"



---------------------------

End of C.S.M.P. Digest
**********************